home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 / Ham Radio 2000.iso / ham2000 / tcp_ip / jnos / cmdshelp / rip < prev    next >
Text File  |  1994-08-16  |  14KB  |  394 lines
  1.  
  2. rip <subcommand>
  3.  
  4.  
  5.      The commands given here are used for RIP.  After this list of
  6. commands is the list for RIP-2.  The RIP-2 implementation includes
  7. compatibility with RIP-1.  The sets of commands are separated here to
  8. improve clarity.
  9.  
  10.      
  11.  
  12.     rip accept <gateway>
  13.  
  14.      Remove the specified gateway from  the  RIP  filter  table,
  15.      allowing  future broadcasts from that gateway to be accepted.
  16.      
  17.  
  18.     rip add <hostid> <seconds> <flags>
  19.  
  20.      Add an entry to the RIP broadcast table. The IP routing table
  21.      will be sent to <hostid> every interval of seconds. If <flags> is
  22.      specified as 1, then "split horizon" processing will be performed
  23.      for this destination. That is,  any  IP routing  table  entries
  24.      pointing  to the interface that will be used to send this update
  25.      will be removed from the update.  If split horizon processing  is
  26.      not  specified,  then all routing table entries except those
  27.      marked "private" will be sent in each update.  (Private entries
  28.      are never sent in RIP packets).  If flags is 2, the broadcast
  29.      will also advertise a route to the system itself.  Flags are
  30.      accumalative, ie a value of 3 will mean both "split horizon" and
  31.      "me too".  See also the 'route' command.
  32.      
  33.      Triggered updates are always done.  That is, any change in the
  34.      routing table that causes a previously reachable destination to
  35.      become unreachable will trigger an update that advertises the
  36.      destination with metric 15, defined  to mean "infinity".
  37.      
  38.      Note that for RIP packets to be sent properly to a broadcast
  39.      address,  there must exist correct IP routing and ARP table
  40.      entries that will first steer the broadcast to the correct
  41.      interface and then place the correct link-level broadcast address
  42.      in the link-level destination field.  If a standard IP broadcast
  43.      address convention is used (e.g. 44.26.0.0 or 44.26.255.255) then
  44.      chances are you already have the necessary IP routing table entry
  45.      (unusual subnet or cluster-addressed networks may require special
  46.      attention!)   However, an 'arp add' command will be required to
  47.      translate this address to the appropriate link level broadcast
  48.      address; For example, arp add 44.255.255.255 ax25 qst-0
  49.      for an AX25 packet radio channel. (If there are multiple AX25
  50.      interfaces, make a unique address for each interface.)
  51.  
  52.           
  53.     rip drop <dest>
  54.  
  55.      Remove an entry from the RIP broadcast table.
  56.      
  57.      
  58.     rip kick
  59.  
  60.      Immediate command to send a rip update.
  61.      
  62.      
  63.     rip merge [on|off]
  64.  
  65.      (B)  This flag controls an experimental feature for consolidating
  66.      redundant entries in the IP routing table. When rip merging is
  67.      enabled, the table is scanned after processing each RIP update.
  68.      An entry is considered redundant if the target(s) it covers would
  69.      be routed identically by a less "specific" entry already in the
  70.      table. That is, the target address(es) specified by the entry in
  71.      question must also match the target addresses of the less
  72.      specific entry and the two entries must have the same interface
  73.      and gateway fields. For example, if the routing table contains
  74.  
  75. Dest            Len      Interface      Gateway   Metric  P Timer  Use
  76. 44.2.3.4        32       ax0            44.96.1.2    1    0   0     0
  77. 44.2.3.0        24       ax0            44.96.1.2    1    0   0     0
  78.      
  79.      then the first entry would be deleted as redundant since packets
  80.      sent to 44.2.3.4 will still be routed correctly by the second
  81.      entry. Note that the relative metrics of the entries are ignored.
  82.      
  83.      
  84.     rip refuse <gateway>
  85.  
  86.      Refuse to accept RIP updates from the specified <gateway> by
  87.      adding the gateway to the RIP filter table. It may be later
  88.      removed with the 'rip accept' command.
  89.      
  90.  
  91.     rip request <gateway>
  92.  
  93.      Send a RIP Request packet to the specified <gateway>, causing it
  94.      to reply with a RIP Response packet containing its routing table.
  95.      
  96.     rip status
  97.  
  98.      Display RIP status, including a count of the number of packets
  99.      sent and received, the number of requests and responses, the
  100.      number of unknown RIP packet types, and the number of refused RIP
  101.      updates from hosts in the filter table.  A list of the addresses
  102.      and intervals to which periodic RIP updates are being sent is
  103.      also shown, along with the contents of the filter table.
  104.  
  105.  
  106.     rip trace [0|1|2]
  107.      (B)  This variable controls the tracing of incoming and outgoing
  108.      RIP packets. Setting it to 0 disables all RIP tracing. A value of
  109.      1 causes changes in the routing table to be displayed, while
  110.      packets that cause no changes cause no output.  Setting the
  111.      variable to 2 produces maximum output, including tracing of RIP
  112.      packets that cause no change in the routing table.
  113.      
  114.     rip ttl <seconds>
  115.  
  116.      (B)  Displays or sets the time to live timer to 'seconds'. Normal
  117.      time-out value is 240 seconds.  This is not the ttl in a rip
  118.      broadcast (16 = infinite).  Set this timer before starting rip.
  119.      Change this timer only in cooperation with your surrounding
  120.      nodes.   Default is 240 seconds.
  121.      
  122.      End of RIP-1 commands.
  123.      
  124. *********************************************************************
  125.      
  126.  
  127.      The following text is provided by N0POY who did the NOS
  128. implementation of RIP-2.
  129.  
  130.      This document covers the implementation of RIP-2 (RFC 1388) in
  131. NOS.  Specifically the WG7J version of NOS.  RIP-2 is an enhanced
  132. version of the RIP protocol (RFC 1058).  RIP and RIP-2 are an interior
  133. gateway protocol (IGP).  RIP-2 for NOS was implemented by Jeff White,
  134. N0POY.
  135.  
  136.      This documentation is for the beta release V0.9 of RIP-2
  137.  
  138.  
  139.     RIP-2 Features
  140.  
  141.  
  142.      The NOS implementation implements all features of the normal RIP
  143. protocol (RFC 1058) and all features of the RIP-2 protocol (RFC 1388)
  144. except multicasting (which NOS does not currently implement) and Route
  145. Tags (NOS does not implement any EGPs).
  146.  
  147.  
  148.      Features include:
  149.         
  150.         Routing Domains
  151.         
  152.         Authentication
  153.         
  154.         Proxy routing
  155.         
  156.         Filtering of naughty nodes
  157.         
  158.         Optional refusal of a default route
  159.  
  160.         Enhanced logging and tracing
  161.         
  162.         Route subnet masks correctly maintained
  163.         
  164.         Optional refusal to accept older RIP version broadcasts
  165.         
  166.         Mixing of RIP-1 and RIP-2 support
  167.      
  168.     NOS RIP COMMANDS
  169.  
  170.  
  171.  
  172.     RIP ACCEPT <gateway>
  173.  
  174. The RIP ACCEPT command resumes the acceptance of RIP broadcasts from a
  175. specific node given in the <GATEWAY> field.
  176.  
  177.           RIP ACCEPT 192.55.248.1  or
  178.           
  179.           RIP ACCEPT skeggi.tcman.ampr.org
  180.  
  181.  
  182.  
  183.     RIP ADD <DEST> <INTERVAL> [<FLAGS>] [<RIPVER>] [AUTH <PASSWORD>]
  184.     [RD <routing domain>]
  185.  
  186.  
  187.  
  188.  
  189.      The RIP ADD command adds a node to the list of stations that are
  190.      to be broadcast to with the local nodes routing table.
  191.  
  192.         <DEST> is the destination node, usually a broadcast address.
  193.         <INTERVAL> is the number of seconds between broadcasts.
  194.         <FLAGS> are the RIP flags used (see below for the flags), it
  195.                   is a hexadecimal number.
  196.         <RIPVER> is the version of the RIP broadcasts.  This may be a
  197.                   1 or 2.  The AUTH identifier preceeds the
  198.                   authentication password to be included with the RIP
  199.                   broadcasts to this destination.
  200.         The RD identifier preceeds the routing domain number.  This
  201.                   number must range from 0 to 65535.
  202.         
  203.      The authentication fields and routing domain fields are only
  204.      valid with RIP-2 broadcasts.  The password must be 16 characters
  205.      or fewer.  Printable ASCII characters are recommended, but not
  206.      required.
  207.  
  208.  
  209.     RIP FLAGS
  210.  
  211.  
  212.      0x01 Do 'split horizon' processing
  213.  
  214.      0x02 Include ourselves in the routing broadcast
  215.      
  216.      0x04 Broadcast RIP packets (default type)
  217.      
  218.      0x08 Multicast RIP packets (not implemented) (RIP-2)
  219.      
  220.      0x10 Poisoned Reverse on
  221.      
  222.      0x20 Authentication data to be included in broadcast (RIP-2)
  223.  
  224.  
  225.  
  226.      Recommend flags are Split Horizon, and Poisoned Reverse or 0x11.
  227.      Authentication and routing domain data entered here only applies
  228.      to the outgoing RIP broadcasts.  See RIP AUTHADD and RIP AUTHDROP
  229.      for entering acceptable passwords and routing domains.
  230.  
  231.  
  232.  
  233.           Example:
  234.           
  235.           RIP ADD SKEGGI.TCMAN.AMPR.ORG 30 0x31 2 AUTH frodo RD 2
  236.  
  237.           RIP ADD BIGGUS.TCMAN.AMPR.ORG 300 0x11 1
  238.  
  239.  
  240.     RIP PROXY <SRC> <DEST> <INTERVAL> [<FLAGS>] [AUTH <PASSWORD>
  241.     [RD <ROUTING DOMAIN>]
  242.  
  243.  
  244.      The RIP PROXY command adds a node to the list of stations that
  245.      are to be broadcast to with the local nodes routing table.
  246.  
  247.         <SRC> is the node that the broadcast will "point" to.
  248.         <DEST> is the destination node, usually a broadcast address.
  249.                   <INTERVAL> is the number of seconds between
  250.                   broadcasts.
  251.         <FLAGS> are the RIP flags used (see below for the flags), it
  252.                   is a hexadecimal number.
  253.         The AUTH identifier preceeds the authentication password to be
  254.                   included with the RIP broadcasts to this
  255.                   destination.
  256.         The RD identifier preceeds the routing domain number.  This
  257.                   number must range from 0 to 65535.
  258.      
  259.      The authentication fields and routing domain fields are only
  260.      valid with RIP-2 broadcasts.  The password must be 16 characters
  261.      or fewer.  Printable ASCII characters are recommended, but not
  262.      required.
  263.  
  264.  
  265.     RIP FLAGS
  266.  
  267.         0x01   Do split horizon processing
  268.         
  269.         0x02   Include ourselves in the routing broadcast
  270.         
  271.         0x04   Broadcast RIP packets (default type)
  272.         
  273.         0x08   Multicast RIP packets (not implemented) (RIP-2)
  274.         
  275.         0x10   Poisoned Reverse on
  276.         
  277.         0x20   Authentication data to be included in broadcast (RIP-2)
  278.         
  279.  
  280.      Recommend flags are Split Horizon, and Poisoned Reverse or 0x11.
  281.      Authentication and routing domain data entered here only apply to
  282.      the outgoing RIP broadcasts.  See RIP AUTHADD and RIP AUTHDROP
  283.      for entering acceptable passwords and routing domains.
  284.  
  285.      Proxy RIP is tricky, complex and not needed for normal use.  Do
  286.      NOT use proxy rip unless you understand what you are doing.
  287.      Proxy RIP's primary use would be to advertise routes to another
  288.      machine that is aquiring routing information via another routing
  289.      protocol.  See RFC 1388 for further details.
  290.  
  291.  
  292.  
  293.     RIP DROP <dest> [<DOMAIN>]
  294.  
  295. RIP DROP removes a routing broadcast entry.  If a RIP-2 broadcast was
  296. entered, the correct routing domain needs to be entered, since it is
  297. possible to broadcast multiple routing domains to the same address.
  298.  
  299.           Example:
  300.           
  301.           RIP DROP SKEGGI.TCMAN.AMPR.ORG 2
  302.  
  303.  
  304.     RIP AUTHADD <interface> <routing domain> [<password>]
  305.  
  306.      RIP AUTHADD adds an acceptable routing domain and optionally a
  307.      password to a specific interface.
  308.  
  309.           Example:
  310.  
  311.           RIP AUTHADD ax0 2 frodo
  312.  
  313.           RIP AUTHADD en0 3
  314.  
  315.  
  316.     RIP AUTHDROP <interface> <routing domain>
  317.  
  318.      RIP AUTHDROP removes an acceptable routing domain (and password
  319.      if any) from a specific interface.
  320.  
  321.  
  322.           Example:            
  323.           RIP AUTHDROP ax0 2
  324.  
  325.     RIP REJECT <version>
  326.  
  327.      RIP REJECT is used to ignore older RIP broadcasts, as they may
  328.      cause undesirable routing table alterations.  The version number
  329.      is the version number and below that are ignored.  RIP version 0
  330.      (XNS RIP) is always ignored.  The default is 0.
  331.  
  332.      To ignore RIP-1 broadcasts:  RIP REJECT 1 would do the job.
  333.  
  334.  
  335.     RIP FILTER <ON|OFF>
  336.  
  337.      RIP FILTER will cause advertisements to the default route
  338.      (0.0.0.0) to be tossed and ignored.  By default this is off.
  339.      
  340.      This can serve as a LID filter.  Default routes should NOT be
  341.      advertised, unless there is a specific reason (ie this machine is
  342.      a gateway to the rest of the Internet).
  343.  
  344.     RIP MERGE <ON|OFF>
  345.  
  346.      RIP MERGE will cause overlapping routing entries to be merged
  347.      into one routing entry.
  348.      
  349.      For example N0BEL.TCMAN.AMPR.ORG is a route to 192.133.30.0/28,
  350.      and 192.133.30.16/28, with merging on this would become a single
  351.      entry of 192.133.30.0/27.
  352.  
  353.  
  354.     RIP REFUSE <gateway>
  355.  
  356.      RIP REFUSE will reject all RIP broadcasts from the GATEWAY
  357.      station.  RIP ACCEPT is the opposite.  By default all stations
  358.      are accepted.
  359.  
  360.  
  361.     RIP REQUEST <GATEWAY>
  362.  
  363.      RIP REQUEST asks the gateway station to send a routing table now,
  364.      rather than waiting for periodic updates.
  365.  
  366.  
  367.     RIP STATUS
  368.  
  369.      RIP STATUS will display various statistics for RIP-1 and RIP-2,
  370.      RIP broadcasts, RIP refusals, and acceptable Interface, Domain
  371.      and Password combinations.  It also displays the refusing version
  372.      level.  The DEFAULT interface is for every interface.  Thus
  373.      unless removed, and RIP-2 broadcast with a domain of 0 does not
  374.      require a password and will be accepted.
  375.  
  376.  
  377.     RIP TRACE <level> [<FILE>]
  378.  
  379.  
  380.      RIP TRACE will begin tracing RIP operations.  The higher the
  381.      level, the more detailed the logging.  Level 9 is the useful
  382.      maximum, with level 0 (the default) being no logging.  If a file
  383.      is specified, logging will go to that file, else logging appears
  384.      on the console.
  385.  
  386.     RIP TTL <time-To-LIVE>
  387.  
  388.      RIP TTL sets the time-to-live before RIP entries expire from the
  389.      routing tables.  The default should work for almost all cases.
  390.  
  391.      End of RIP-2 Description
  392.      
  393.  
  394.